Skip to content

feat(codegen): add WarmUpOperationSelector to pick the CRaC warm-up operation#7135

Open
joviegas wants to merge 2 commits into
feature/master/crac_auto_priming_supportfrom
joviegas/warmup_op_selector
Open

feat(codegen): add WarmUpOperationSelector to pick the CRaC warm-up operation#7135
joviegas wants to merge 2 commits into
feature/master/crac_auto_priming_supportfrom
joviegas/warmup_op_selector

Conversation

@joviegas

@joviegas joviegas commented Jul 12, 2026

Copy link
Copy Markdown
Contributor

Motivation and Context

CRaC auto-priming needs the generated ServiceWarmUpProvider.warmUp() to invoke one API operation with a synthetic request so the marshal/sign/unmarshal path is JIT-compiled before checkpoint. Not every operation is safe or useful for this call. This PR adds the codegen-time logic that picks the right operation per service. Wiring the selected operation into the generated warmUp() body comes in a follow-up PR.

Modifications

Added WarmUpOperationSelector, a codegen utility that selects one operation per service in two steps:

  1. Filter out operations that cannot be called with an all-null request. Removed: streaming or event-stream operations (they need extra arguments and special response handling), and deprecated operations.

  2. Rank the remaining operations by: returns output (so the unmarshaller is primed too), is authenticated (so signing is primed too), verified simple method, accepts an empty request, fewest required input members, read-only verb (List over Describe over Get), then operation name for a deterministic tie-break.

Returns Optional.empty() when no operation survives the filter; the consumer will generate a no-op provider in that case.

Testing

  • Junits

License

  • I confirm that this pull request can be released under the Apache 2 license

@joviegas joviegas requested a review from a team as a code owner July 12, 2026 16:33
@joviegas joviegas force-pushed the joviegas/warmup_op_selector branch 5 times, most recently from e2bce8e to ff16b58 Compare July 13, 2026 15:01
@joviegas joviegas force-pushed the joviegas/warmup_op_selector branch from ff16b58 to 8a81efb Compare July 13, 2026 15:02

@alextwoods alextwoods left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the PR description doesn't quite match the actual order that we have. ie, "Rank the remaining operations by fewest required input members, then verified simple method" doesn't match the actual order that I think is has output, verified simple, empty request, ect....


return BY_HAS_OUTPUT_FIRST
.thenComparing(byVerifiedSimpleFirst)
.thenComparing(BY_EMPTY_REQUEST_FIRST)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we also add a sort that prefers operations that have auth (ie, we don't prefer an option with noAuth since it wouldn't help us warm up signing related code)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice point 👍 Added now.

* tie-break.
*/
private static Comparator<OperationModel> warmUpPreference(List<String> verifiedSimpleMethods) {
Comparator<OperationModel> byVerifiedSimpleFirst =

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this isn't a constant like the others (eg, BY_EMPTY_REQUEST_FIRST)?

private static final List<String> PREFERRED_VERBS = Arrays.asList("List", "Describe", "Get");

private static final Comparator<OperationModel> BY_EMPTY_REQUEST_FIRST =
Comparator.comparing(op -> !acceptsEmptyRequest(op));

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a personal readability preference - feel free to ignore - but I have a slightly hard team reading both the ! and then translating the true/false to compare order - what about:

Comparator.comparing(op -> acceptsEmptyRequest(op) ? 0 : 1);

* call as a warm-up.
*/
public static Optional<OperationModel> selectWarmUpOperation(IntermediateModel model) {
List<String> verifiedSimpleMethods = model.getCustomizationConfig().getVerifiedSimpleMethods();

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this is ever possible or not, but do we need to handle null here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No its not possible to be null here because its initialized as empty list

@joviegas

Copy link
Copy Markdown
Contributor Author

It looks like the PR description doesn't quite match the actual order that we have. ie, "Rank the remaining operations by fewest required input members, then verified simple method" doesn't match the actual order that I think is has output, verified simple, empty request, ect....

Updated the description , added auth too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants